cc @hjdivad

@stefanpenner something we didn't do was separate measurements gain of reexport vs not doubling the arglist. Probably most of the gain came from reexport but if not that might suggest that there's some gain to be made in minifying module names & deps.

@hjdivad ya we should

Wow, this would be awesome if it lands

@eviltrout @samsafron this may interest you

new V8 side improvements: v8/v8@33ec0b7

cc @SamSaffron

For anyone interested and motivated this will likely be a non-trivial amount of work to complete, but totally possible.

I will gladly make myself available via google hangout (or in person if you are relatively local to me) to come up with plan of attack.

cc @dgeb this is somewhat related to your container work, so you may also be on-board.

note: this should also play into the future "swelt" builds and tree shaking plans

@stefanpenner I think I will have time to help this this. Startup time improvement is certainly something I'd like to improve.

Could you briefly explain me a bit more how to tackle it and in particular how to benchmark if i'm making progress?

Also I know that ember itself was about to get refactored into es6 modules. Will be better to wait for that before tacking this? Alternatively if the modules structure has been fully decided I could modularize the internals myself.

@cibernox I would love to have you help with this, I believe this work and land incrementally and will likely only improve the pure es6 build of the future.

We should sync up on a hangout later this week.

After @krisselden and I did investigation around this I'm not sure where the value add is. In Ember you need roughly all of the modules upfront and it's better to make these eager rather than lazy to avoid V8's lazy-preparse on modules that you need pretty much immediately. We hope to upstream the work we did to allow for the overhead of the internal to be much less. The only thing blocking this is refactoring the broccoli plugin Kris and I worked on to account for the new "index" files and some circular dependencies on ember-debug.

More longer term I believe the packages themselves need to be refactored to explicitly expose APIs and that the packages use rollup to tree shake and create 1 large module per package.

@chadhietala that isn't true.

Many costly modules are included and ultimately instantiated by mistake. In addition this is also an incremental step to continue to decouple and improve the lazy/eager/svelte plans.

Without this step, we will hinder future work and with it we will see improvements incrementally.

One of the issues I ran into looking into this work was the circular includes in the tests.

@kiwiupover yes. a large included task here is some much needed cleanup. Which will nicely compound value with some future plans.

@stefanpenner what is the next step in unraveling the tests to remove the circular dependencies.

@stefanpenner what is the next step in unraveling the tests to remove the circular dependencies.

I believe you just described the next task in fix test-suite

@stefanpenner too right it is the next task. I want to help I will hit up @krisselden for help.

@stefanpenner @chadhietala So, at the end, is still unclear if this will bring performance benefits? I just have some OSS time that I'd like to use to tackle the modularization of ember itself to bring tree shaking asap to the ember ecosystem, and I thought this could be helpful to gain some knowledge about how ember is divided internally.

@stefanpenner @chadhietala So, at the end, is still unclear if this will bring performance benefits?

their are performance benefits.

In Ember you need roughly all of the modules upfront

Many modules are not, for example in my tests 20% total worth of just HTMLBars modules which ember totally overrides.

A quick-scan of https://github.com/emberjs/ember.js/blob/master/packages/ember-application/lib/system/application.js#L1046-L1104 already yields many eager registrations that should become pay-as-you-go. Remember our plan is to work towards svelte builds, if we are forced to eagerly consume everything that doesn't work.

How many apps use all of Ember.Select, LegacyEach, Checkbox, TextArea, TextField and all of the locations services? Individually these may not seem relevant, but when we compound all the extra baggage is adds up quickly.

If we follow those optional pieces back we will see they are the retainers of many more modules. The remaining retainers of costly & potentially un-used code can then be focused on.

One example of this is, CollectionView which view/index eagerly consumes but is actually guarded behind ENABLE_LEGACY_VIEW_SUPPORT, which actually guards more accidentally eagerly compute modules:

• Ember.CoreView
• Ember.View
• Ember.View.states
• Ember.View.cloneStates
• Ember.View._Renderer
• Ember.ContainerView;
• Ember.CollectionView;

A bonus, as we make these lazy they will be easier to extract as add-ons, further reducing byte size.

and it's better to make these eager rather than lazy to avoid V8's lazy-preparse on modules that you need pretty much immediately.

This is actually unclear to me, my experiments suggested we will need to tune this and one way or the other wont be ideal.

It is also worth noting, especially as users want to run small parts of their apps in service-workers or web-workers, we shouldn't force them to eagerly pay for the aspects of ember they wont use (like the view layer).

@stefanpenner is this still relevant?